the perfect app

rules and guidelines for creating the perfect app

[ Guidelines | Questions | Examples ]

This page is dedicated to show developers and users how to create the perfect app. It isn't as hard as it sounds. Here you will find examples of over blown apps, and perfect ones, as well as guidelines or creating your own app, and making it perfect. Let's get started.

..:: Guidelines ::.

Although there are many important things about the perfect app, there are 3 that stand out the most. They don't apply to all apps, but here they are, in random order:

1. Interface. The interface is what makes an app pretty, or could ruin a good app. I'm talking mainly about Win32 applications, since DOS apps usually are just run like "delete /all". A good interface is a clean one. I have seen good apps with a not so good interface, and also bad apps with a nice interface. Here is an ever-growing list of things to do and not to do with your app's interface.

  • Don't have your companies name written across the bottom of the app. Not only does it make the interface that much uglier, but it makes the app look like shareware.
  • Don't combine freeware and shareware. It is either absolutely free (no ads, no nag screens, no registration), or it is shareware. Choose one or the other. Don't combine them.
  • Don't use 16 bit icons, unless it is only for Windows 95. Windows 98 + can use 32 bit icons. 32 bit icons look nicer than the 16 bit ones. If you can, 32 bit icons are the way to go.
  • Test your app in: small fonts, large fonts, and different screen resolutions before releasing it. On my system, I use large fonts most of the time. Some apps have to be resized immediately after they are opened, because the text cuts off. Not very attractive.
  • Don't over due the interface. Just because you can doesn't mean you should. Just because you learned from a top secret Visual Basic site how to customize a scrollbar doesn't mean you should add one in. See the [ Examples ] page for some apps to learn from.
  • Make it clean. Don't use a bunch of different fonts throughout the program. Don't use every possible color you can on the app. Have some sort of theme. The more you add to an app, the slower it loads, and the bigger it is. Keep it simple.

2. Stability. Even if an app has a perfect interface, you don't want it crashing every three seconds. If someone is reading through Download.com's comments section on an app, and hears one thing about crashing a computer, it probably won't be downloaded.

  • Stay away from window animation. All the newbie programmers all want to have their app fall in from the top of the screen. If this app is frequently used, this gets really annoying. Unless you know what you are doing, stay away from it. See [ Examples ]
  • Don't release an unstable program, unless it is an alpha / beta. In testing, bugs are usually excused. On final releases, however, they are not. Nobody wants their app to have a bad first impression.
  • Test is on different computers with different operating systems. You may find out that you need a certain file to make it run, that your computer has, but others don't.
  • If your app is incompatible with another program, say that in the readme. Better the end user knowing before, than having it crash.

3. Features / Usefulness. Your app has to do something. And it should be good at what is does.

  • Don't combine a bunch of features into one app, unless it makes sense. Would you use a toaster built into a car? Probably not. An app that minimizes all windows shouldn't have a feature to stick Post-it notes on the desktop, or launch Word. The exception is all-in-one apps like Power Tools. See [ Examples ]
  • Decide whether or not to make it customizable. An app that launches notepad probably shouldn't have any options. An app that is bigger and more advanced should usually have options. But don't have too many options. The more options, the harder the program is to learn, and could put stability at risk.
  • Your program should be useful. If it isn't there is no sense having it. It should also be good at what it does. A couple people might want a program that skips ahead 4.5 seconds while Winamp is playing a 128-bit WMA file, but most people won't really care about that.
  • Show how the features work. In a help file, readme, or website. There's no sense having loads of features, but no clue what they do.

[ Questions ]